In a telecommunication network described by the 3rd Generation Partnership Project (3GPP), main functions of GTP′ (a GPRS Protocol, used for CDR transport) V2 are described as follows.
FIG. 1 shows relationship between a Charging Trigger Function (CTF), a Charging Data Function (CDF) and a Charging Gateway Function (CGF), where the Ga interface is a communication interface for transmitting Charging Data Records (CDRs) from the CDF to CGF, and the Ga interface complies with the GTP′.
FIG. 2 shows bearers of the GTP′. It can be seen from the figure that the GTP′ may be based on a User Datagram Protocol (UDP) or a Transmission Control Protocol (TCP).
The GTP′ is mainly defined as follows.
I) GTP′ Message Header
The GTP′ message header reuses the General Packet Radio Service Tunneling Protocol (GTP) message header (GTP Message Header), as shown in FIG. 3, in the GTP Message Header, several flag bits (such as Version, PT, etc.), the message type, the length and the sequence number are defined, where Version refers to a version number, and PT refers to a protocol type.
II) GTP′ Message Type
Below are types of messages used by the GTP′, the first three types reuse the message type of the GTP, and the following six types are newly-added message types of the GTP′.
1. Echo Request (a handshake request sending to a correspondent node);
2. Echo Response (a response to a handshake request from a correspondent node);
3. Version not supported (a response indicating that a current node does not support version of a message sent by a correspondent node and notifying the newest version number which the current node can support, this message does not need to be responded to);
4. Node Alive Request (a notification to a correspondent node that the current node is alive);
5. Node Alive Response (a response to a Node Alive Request from a correspondent node);
6. Redirection Request (a notification of CGF to GSN, and instructing GSN to send a data record to other CGFs);
7. Redirection Response (a response to a Redirection Request from CGF by GSN);
8. Data Record Transfer Request (GSN sending a Data Record Packet to CGF); and
9. Data Record Transfer Response (a response to a Data Record Transfer Request from GSN by CGF).
Among the above messages, the Data Record Transfer Request and the Data Record Transfer Response are messages used when CDRs are transmitted, and they are the core content of the GTP′.
Specifically, the structure of the Data Record Transfer Request is as shown in Table 1, it may include the following five Information Elements (IEs):
1. Packet Transfer Command;
2. Data Record Packet;
3. Sequence Numbers of Released Packets;
4. Sequence Numbers of Cancelled Packets; and
5. Private Extension.
TABLE 1Information ElementPresence requirementPacket Transfer CommandMandatoryData Record PacketConditionalSequence Numbers of Released PacketsConditionalSequence Numbers of Cancelled PacketsConditionalPrivate ExtensionOptional
Wherein the Packet Transfer Command is a mandatory parameter, and currently it has the following four values:
1) 1=‘Send Data Record Packet’:
Then, an IE, namely, Data Record Packet is mandatory, and the structure of the IE is as shown in Table 2.
TABLE 2ClassOctetsDataNoteIE-T1Type = 252Indicating IE-DataRecord PacketIE-L2 . . . 3Lengthwhen Length == 0,indicating that a NULLpacket is sentIE-V4Number of Data Records5Data Record Format1: BER,2: PER(unaligned),3: PER(aligned)6 . . . 7Data Record FormatVersion8 . . . 9Length of Data Record 110 . . . nData Record 1. . .x . . . x + 1Length of Data Record Nx + 2 . . . yData Record N
2) 2=‘Send possibly duplicated Data Record Packet’:
Then, an IE, namely, Data Record Packet is mandatory, and the structure of the IE is as shown the aforementioned Table 2.
When there are multiple CGFs in the current network, due to a network malfunction of CGF1, a Data Record Packet sent by a GPRS Supported Node (GSN) to CGF1 is not responded in time, then the GSN may send a same Data Record Packet, in the form of a command ‘Send possibly duplicated Data Record Packet’, to CGF2 (standby CGF); after receiving such a data packet, CGF2 will temporarily cache it locally, and it is not until CGF2 receives a command ‘Cancel/Release Data Record Packet’ from a data packet corresponding to the GSN that the CGF2 may delete the possibly duplicated Data Record Packet cached locally (Cancel) or release the possibly duplicated Data Record Packet to a normal data record directory.
3) 3=‘Cancel Data Record Packet’:
Then, an IE, namely, Sequence Numbers of Cancelled Packets is mandatory, and the structure of the IE is as shown in Table 3.
TABLE 3ClassOctetsDataNoteIE-T1Type = 250Indicating IE-Sequence NoCancelIE-L2 . . . 3LengthIE-V4 . . . 5Sequence Number 1n . . . n + 1Sequence Number N
4) 4=‘Release Data Record Packet’:
Then, an IE, namely, Sequence Numbers of Released Packets is mandatory, and the structure of the IE is as shown in Table 4.
TABLE 4ClassOctetsDataNoteIE-T1Type = 249Indicating IE-Sequence NoReleaseIE-L2 . . . 3LengthIE-V4 . . . 5Sequence Number 1n . . . n + 1Sequence Number N
A Data Record Transfer Response message is used by CGF to respond to a Data Record Transfer Request message, and the structure of the message Data Record Transfer Response is as shown in Table 5.
TABLE 5Information ElementPresence requirementCauseMandatoryRequests RespondedMandatoryPrivate ExtensionOptional
This message must include two types of IEs: Cause and Requests Responded, wherein the Cause represents a response result (the reason for reception or rejection); and the Requests Responded represents the sequence number of a successfully-received Data Record Packet, the structure of which is as shown in Table 6, the IE can include sequence numbers of multiple Data Record Packets, that is to say, one Data Record Transfer Response message can respond to multiple Data Record Transfer Requests.
TABLE 6ClassOctetsDataNoteIE-T1Type = 253Indicating IE-SequenceRespondedIE-L2 . . . 3LengthIE-V4 . . . 5Sequence Number 1n . . . n + 1Sequence Number N
Data Record Packet transmission methods in GTP′ include the following three cases:
Case 1, Data Record Packet transmission is implemented in normal circumstances, and the transmission process is as shown in FIG. 4, which mainly includes the following steps:
Step 401: A GSN sends a Data Record Packet to a CGF, and the corresponding message is a Data Record Transfer Request, wherein the Packet Transfer Command parameter is Send Data Record Packet, and the sequence number in the message header is N.
Step 402: The CGF receives and processes the message, and stores locally the data record included in the Data Record Packet.
Step 403: The CGF sends a response message to the GSN, and the message content is a Data Record Transfer Response, wherein the Requests Responded parameter includes the sequence number N, and the Cause parameter is set to Request Accepted.
Step 404: After receiving the Data Record Transfer Response message, the GSN deletes from the cache the Data Record Packet with a sequence number of N.
If failing to receive a response, the GSN may resend the request within a specified interval and for a preset number of times.
Case 2, a GSN and CGF1 is disconnected, and the transmission process is as shown in FIG. 5, which mainly includes the following steps:
Step 501: A GSN sends a Data Record Transfer Request message to CGF1 (primary CGF), wherein the Packet Transfer Command parameter is Send Data Record Packet, and the sequence number of the message header is M.
Step 502: Since the GSN loses communications with CGF1, CGF1 does not receive a Data Record Packet.
Step 503: The GSN cannot receive a response.
Step 504: The GSN detects (by Echo Request) its link with CGF2 (standby CGF), and if the link is normal, the GSN sends, the same Data Record Packet as sent to CGF1, to CGF2 by the Data Record Transfer Request message, wherein the Packet Transfer Command parameter is Send possibly duplicated Data Record Packet, and the sequence number in the message header is N.
Step 505: CGF2 receives and processes the Data Record Packet, since the Data Record Packet is identified as possibly duplicated, CGF2 only caches the Data Record Packet, and does not immediately send it to a Billing system (BS).
Step 506: CGF2 sends a correct reception acknowledgement message to the GSN by a Data Record Transfer Response message, wherein the Requests Responded parameter includes the sequence number N, and the Cause parameter is set to Request Accepted.
Step 507: The GSN can delete the Data Record Packet successfully sent (which may be duplicated), but still retain the sequence numbers of the Data Record Packet sent to CGF1 and CGF2 (i.e., M and N).
Step 508: After being recovered, CGF1 sends a Node Alive Request message to the GSN, and the GSN learns that it can communicate with CGF1.
Step 509: The GSN acknowledges by a Node Alive Response message.
Step 510: For the Data Record Transfer Request message not acknowledged above (in Step 501), the GSN sends a null testing Data Record Packet to CGF1, and the null Data Record Packet is a packet in which only data of data records is not included in the Data Record Packet parameter and others remain the same (the sequence number in the message header is still M).
Step 511: CGF1 responds with a Data Record Transfer Response message, wherein the Requests Responded parameter includes the sequence number M, and the Cause parameter is set to Request Accepted. Since the GSN has already lost contact with CGF1, CGF1 does not receives any Data Record Packet, and thus CGF1 regards the testing Data Record Packet as a new one and can accept it.
Step 512: After receiving a response message from CGF1, the GSN learns that CGF1 does not process the testing Data Record Packet, and notifies CGF2 that it can send the testing Data Record Packet to the BS, the message adopted is a Data Record Transfer Request, and the Packet Transfer Command parameter is Release Data Record Packet. The Sequence Numbers of the Released Packets parameter includes the sequence number N.
Step 513: CGF2 sends the Data Record Packet to the BS.
Step 514: CGF2 sends a Data Record Transfer Response message to the GSN, where the Requests Responded parameter includes the sequence number N, and the Cause parameter is set to Request Accepted.
Case 3, a link between a GSN and CGF1 is disconnected after a Data Record Packet is correctly received, and the transmission process is as shown in FIG. 6, which mainly includes the following steps:
Step 601: A GSN sends a Data Record Transfer Request message to CGF1 (primary CGF), wherein the Packet Transfer Command parameter is Send Data Record Packet, and the sequence number of the message header is M.
Step 602: After receiving the Data Record Packet, CGF1 store safely the data records included in the Data Record Packet.
Step 603: The communications between the GSN and CGF1 is interrupted, and the GSN cannot receive a response from CGF1.
Step 604: The GSN detects (by Echo Request) its link with a standby CGF (CGF2), if the link is normal, the GSN sends, the same CDR as sent to CGF1, to CGF2 by the Data Record Transfer Request message, wherein the Packet Transfer Command parameter is Send possibly duplicated Data Record Packet, and the sequence number in the message header is N.
Step 605: CGF2 receives and processes the Data Record Packet, since the Data Record Packet is identified as possibly duplicated, CGF2 only caches the Data Record Packet, and does not immediately send it to the BS.
Step 606: CGF2 sends a correct reception acknowledgement message to the GSN by a Data Record Transfer Response message, wherein the Requests Responded parameter includes the sequence number N, and the Cause parameter is set to Request Accepted.
Step 607: The GSN can delete the Data Record Packet successfully sent (which may be duplicated), but still retain the sequence numbers of the Data Record Packet sent to CGF1 and CGF2 (i.e., M and N).
Step 608: After being recovered, CGF1 sends a Node Alive Request message to the GSN, and the GSN learns that it can communicate with CGF1.
Step 609: The GSN acknowledges by a Node Alive Response message.
Step 610: For the Data Record Transfer Request message not acknowledged above (in Step 601), the GSN sends a null testing Data Record Packet to CGF1, and the null Data Record Packet is a packet in which only data of data records is not included in the Data Record Packet parameter and others remain the same (the sequence number in the message header is still M).
Step 611: CGF1 responds with a Data Record Transfer Response message, wherein the Requests Responded parameter includes the sequence number M, and the Cause parameter is set to Request related to possibly duplicated packets already fulfilled. Since CGF1 stored the Data Record Packets before losing communications with the GSN, CGF1 considers the testing Data Record Packet as duplicated.
Step 612: After receiving a response message from CGF1, the GSN learns that CGF1 has received and stored the Data Record Packet, and notifies CGF2 to cancel the Data Record Packet, the message adopted is Data Record Transfer Request, and the Packet Transfer Command parameter is Cancel Data Record Packet. Wherein the Sequence Numbers of the Released Packets parameter includes the sequence number N.
Step 613: CGF2 deletes the Data Record Packet from the cache.
Step 614: CGF2 sends a Data Record Transfer Response message to the GSN, wherein the Requests Responded parameter includes the sequence number N, and the Cause parameter is set to Request Accepted.
The existing transmission methods have the following problems:
When CGF1 is interrupted for a period of time, the GSN sends possibly duplicated packets to CGF2. Assuming that the sequence numbers of the possibly duplicated packets are from M to N, since CGF1 is interrupted, the possibly duplicated packets will not be processed temporarily; the current network speed is general high, supposing the traffic volume is up to 10000/s and each data packet only stores one data record, the sequence number will reach M again within less than seven seconds (since the maximum sequence number is 65535); then if a further Data Record Packet is desired to be sent, the sequence numbers from M to N must be bypassed, that is to say, after a new sequence number reaches M−1, the sequence number of the next Data Record Packet is not M but N+1; otherwise, after the CGF responds to packets with the sequence numbers from M to N, the GSN cannot judge whether the sequence number of the possibly duplicated packet or the normal packet is responded. Though the above problem can be solved by bypassing the sequence numbers from M to N, a situation in which the quantity of available sequence numbers is reduced will be resulted in, supposing an Echo Request is sent every 3 seconds and a link is considered as disconnected only when an Echo Response is not received for three consecutive times, the GSN will not learn, within 9 seconds, that its link with CGF1 is disconnected, instead, the GSN will send consecutively 65535 Data Record Packets to CGF1, but CGF1 can respond to none of them, so that the possibly duplicated packets will exhaust all the sequence number resources, thus resulting in the GSN not being able to communicate normally with CGF2. It should be noted that even if the number of the possibly duplicated packets sent by the GSN to CGF2, due to and after the disconnection between the GSN and CGF1, does not reach 65535, and if subsequent disconnections between the GSN and CGF3 or other CGFs result in accumulation of possibly duplicated packets between GSN and CGF2, it will eventually result in the situation in which sequence number resources between the GSN and CGF2 are exhausted. The above process is shown in FIG. 7, and the procedures are described as follows.
Step 701: A GSN sends consecutively multiple packets to CGF1, the sequence numbers are from X to Y.
Step 702: CGF1 is in essence interrupted.
Step 703: CGF1 does not give any response to the GSN.
Step 704: The GSN learns that its link with CGF1 is interrupted, and redirects to CGF2.
Step 705: The GSN sends possibly duplicated packets with the sequence numbers from X to Y to CGF2, and the sequence numbers correspond to sequence numbers from M to N of CGF2.
Step 706: The GSN constantly sends new data records to CGF2, resulting in sequence numbers of new Data Record Packets back to M−1.
Step 707: If a next Data Record Packet is desired to be sent, the sequence number must bypass M to N, i.e., the sequence number of the next Data Record Packet is N+1.
In addition, there is another case in the prior art: the protocol enables the CGF to manually release/delete possibly duplicated packets, but after the CGF releases/deletes the possibly duplicated packets, the GSN does not learn of that, and the GSN still maintain these possibly duplicated packets manually released/deleted by the CGF (including sequence numbers), this will result in that possibly duplicated packets maintained by the GSN become more and more, and when the numbers of possibly duplicated packets maintained by the GSN is close to 65535, communication cannot be proceeded any more, thereby bringing great hidden dangers to the stability of a program.
It can be seen that the above case in which possibly duplicated packets occupy a great amount of sequence number resources hardly happens when the traffic volume is relatively small, thus the above problem may also be solved if the quantity of Data Record Packets sent within a unit time is limited, but this will also limit the data transmission rate in normal circumstances and waste a great amount of bandwidth. If the range of sequence numbers is extended alone, such as being extended from WORD to DWORD, first comes the problem of protocol compatibility, and the problem of duplication of possibly duplicated packets and normal packets cannot be solved neither (since for a rate of 10000/s, sequence numbers of DWORD will also duplicate after the interruption of CGF1 for 120 hours).
At present, the development of hardware is rapid, and service providers have higher and higher requirements on the transmission rate of data records, it is a moderate requirement for the data record processing rate to exceed 10000/s, thus in order to solve the above problem, a method, which does not limit network transmission rate and in the mean time can solve the problem that possibly duplicated packets occupy sequence number resources, must be found; however, the prior art cannot provide solutions meeting the above requirements.